Restrict access to compilers #139
Conversation
|
About |
|
I see the point. At this time, we can just disable compilers all together. That is of course a real pain for usability especially for devs. Or this can just be an opt-in feature, using a boot parameter or something else. |
|
design discussion on how to enable/disable this latest draft and discussion here: |
|
As said in the other ticket: So we don't have to parse on/off for each, best to make a syntax similar to systemctl. Here:
|
It's not that difficult. Currently we got:
Overloading permission-hardener with the config management would be difficult indeed. So first step would be renaming permission-hardener to permission-hardener-enable or so. Then the logic of config management could be handled by a new, yet to be invented script. I might get there one day but not a priority right now.
As I said before:
|
|
We might be better off just not touching the compilers and recommending users to uninstall them if they don't do development. This enable-disable solution looks a little too much at the users end. This package would be better if it is just a install and forget kind of thing. |
|
monsieuremre:
We might be better off just not touching the compilers and recommending users to uninstall them if they don't do development.
This won't work. Sometimes compilers or interpreters are dependencies of
other packages.
This enable-disable solution looks a little too much at the users end.
This package would be better if it is just a install and forget kind
of thing.
Yes. The scope of security-misc still isn't well defined and debatable.
Keeping security-misc still useful outside of Kicksecure, Whonix might
mandate not disabling compilers/interpreters by default.
However, most of the code could be in security-misc and then other
packages could have a config snippet or run a command to enable these
protections (compilers lock, interpreter lock).
|
|
I don't find this approach to be productive. Hardening as in 'secure by default' should require no further user interaction, let alone forcing them to run commands with options. So for the time being, we can let the compilers be. I'm closing the issue. |
|
Compiler lock still planned. Ticket here: But this will take time. ( |
This can also be implemented as a script pair.
lock_compilerandlock_compiler_undowith only root having access to these. Then it might be easier to use compilers without root when needed. But this does not remove functionality anyway. We sould just have tosudo gcc.